Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/app/aluno/meus-treinos/meus-treinos-client.tsx">

<violation number="1" location="src/app/aluno/meus-treinos/meus-treinos-client.tsx:138">
P2: When a save request fails, the inline editor is still closed immediately because `setEditingTreinoId(null)` runs right after calling `handleSave(...)` without waiting for success. This regresses the previous behavior where the form stayed open on error, so users can lose what they just typed. A safer flow is to close the inline editor only after a confirmed successful save result.</violation>

<violation number="2" location="src/app/aluno/meus-treinos/meus-treinos-client.tsx:277">
P2: Custom agent: **Enforce Strict Maintainability Standards**

The `__new__` magic-string sentinel overloads `editingTreinoId` to mean both "editing an existing treino" (when it holds a real ID) and "creating a new treino" (when it equals `__new__`). A `string | null` type can only express two states, so the third state is hidden by an implicit convention that every reader must discover. Replacing this with a discriminated union or a dedicated boolean flag would make the state machine explicit and self-documenting, and remove the risk of the sentinel drifting out of sync if it is ever changed in one place but not the other.</violation>
</file>

<file name="src/hooks/use-workout-generation.ts">

<violation number="1" location="src/hooks/use-workout-generation.ts:81">
P2: `planName` state is set inside the success block but never cleaned up when re-invocation fails mid-way. If a second generation is started while the first is still in-flight, `setPlanName(null)` runs immediately but the in-flight success could set `planName` to stale data after the second generation completes. Consider using an abort/mount ref or resetting `planName` only at the start of a new generation (already done) and protecting `setPlanName` from stale completions.</violation>
</file>

<file name="docs/superpowers/plans/2026-07-05-meus-treinos-ux-improvements.md">

<violation number="1" location="docs/superpowers/plans/2026-07-05-meus-treinos-ux-improvements.md:9">
P3: The implementation plan now documents `React 18`, but this repository is on React 19.x. That mismatch can lead to incorrect implementation/testing guidance (especially around runtime/test behavior), so updating the plan to the actual version would keep the UX task instructions reliable.</violation>

<violation number="2" location="docs/superpowers/plans/2026-07-05-meus-treinos-ux-improvements.md:337">
P1: Test mock setup is broken: Step 1 replaces `useWorkoutGeneration: vi.fn(() => ({...}))` with `useWorkoutGeneration: () => ({...})`, dropping the `vi.fn()` wrapper. Then Step 3 attempts `(useWorkoutGeneration as ReturnType<typeof vi.fn>).mockReturnValue(...)` — but since `useWorkoutGeneration` is now a plain arrow function, `.mockReturnValue` is undefined and the test will throw a TypeError at runtime. Keep `vi.fn(() => ...)` in the mock factory so the dynamic override in the banner test works. The `as ReturnType<typeof vi.fn>` cast only silences TypeScript, it doesn't create the mock method at runtime.</violation>
</file>

<file name="src/hooks/use-workout-crud.ts">

<violation number="1" location="src/hooks/use-workout-crud.ts:28">
P2: `editingTreino` and `isFormVisible` state inside `useWorkoutCRUD` is now maintained but unused after the refactor. The consumer (`meus-treinos-client.tsx`) manages its own `editingTreinoId` state and doesn't destructure these from the hook. `handleEdit` still sets them and `handleSave` still resets them, but nothing reads them — creates unnecessary state management overhead and could mislead future maintainers into thinking the hook controls form visibility. Suggest removing `editingTreino`, `isFormVisible`, and their setters from the hook since the consumer owns inline editing state externally.</violation>
</file>

<file name="docs/superpowers/specs/2026-07-05-meus-treinos-ux-improvements-design.md">

<violation number="1" location="docs/superpowers/specs/2026-07-05-meus-treinos-ux-improvements-design.md:69">
P2: The design doc now points implementation to `card-treino.tsx`, while the implementation plan explicitly says inline editing must not be done there. This conflict can send contributors to modify the wrong component path, so aligning both docs to the same target file(s) would avoid rework.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/hooks/use-workout-generation.ts">

<violation number="1" location="src/hooks/use-workout-generation.ts:81">
P2: `planName` state is set inside the success block but never cleaned up when re-invocation fails mid-way. If a second generation is started while the first is still in-flight, `setPlanName(null)` runs immediately but the in-flight success could set `planName` to stale data after the second generation completes. Consider using an abort/mount ref or resetting `planName` only at the start of a new generation (already done) and protecting `setPlanName` from stale completions.</violation>
</file>

<file name="src/app/aluno/meus-treinos/meus-treinos-client.tsx">

<violation number="1" location="src/app/aluno/meus-treinos/meus-treinos-client.tsx:277">
P2: Custom agent: **Enforce Strict Maintainability Standards**

The `__new__` magic-string sentinel overloads `editingTreinoId` to mean both "editing an existing treino" (when it holds a real ID) and "creating a new treino" (when it equals `__new__`). A `string | null` type can only express two states, so the third state is hidden by an implicit convention that every reader must discover. Replacing this with a discriminated union or a dedicated boolean flag would make the state machine explicit and self-documenting, and remove the risk of the sentinel drifting out of sync if it is ever changed in one place but not the other.</violation>
</file>

<file name="docs/superpowers/plans/2026-07-05-meus-treinos-ux-improvements.md">

<violation number="1" location="docs/superpowers/plans/2026-07-05-meus-treinos-ux-improvements.md:9">
P3: The implementation plan now documents `React 18`, but this repository is on React 19.x. That mismatch can lead to incorrect implementation/testing guidance (especially around runtime/test behavior), so updating the plan to the actual version would keep the UX task instructions reliable.</violation>

<violation number="2" location="docs/superpowers/plans/2026-07-05-meus-treinos-ux-improvements.md:337">
P1: Test mock setup is broken: Step 1 replaces `useWorkoutGeneration: vi.fn(() => ({...}))` with `useWorkoutGeneration: () => ({...})`, dropping the `vi.fn()` wrapper. Then Step 3 attempts `(useWorkoutGeneration as ReturnType<typeof vi.fn>).mockReturnValue(...)` — but since `useWorkoutGeneration` is now a plain arrow function, `.mockReturnValue` is undefined and the test will throw a TypeError at runtime. Keep `vi.fn(() => ...)` in the mock factory so the dynamic override in the banner test works. The `as ReturnType<typeof vi.fn>` cast only silences TypeScript, it doesn't create the mock method at runtime.</violation>
</file>

<file name="docs/superpowers/specs/2026-07-05-meus-treinos-ux-improvements-design.md">

<violation number="1" location="docs/superpowers/specs/2026-07-05-meus-treinos-ux-improvements-design.md:69">
P2: The design doc now points implementation to `card-treino.tsx`, while the implementation plan explicitly says inline editing must not be done there. This conflict can send contributors to modify the wrong component path, so aligning both docs to the same target file(s) would avoid rework.</violation>
</file>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/app/aluno/meus-treinos/meus-treinos-client.tsx`:
- Around line 82-92: The plan banner can remain visible forever if a new
generation starts and then fails because the existing timer is cleared by the
`useEffect` cleanup when `planName` becomes null. Update
`meus-treinos-client.tsx` so the banner is explicitly hidden at the start of the
generation flow (for example in `onGenerate` or right before `handleGenerate`
runs) by resetting both `setShowPlanBanner(false)` and
`setBannerPlanName(null)`, instead of relying only on the `planName` effect in
`useEffect`.

---

Nitpick comments:
In `@src/hooks/use-workout-crud.ts`:
- Around line 20-25: In useWorkoutCRUD, remove the redundant edit-form state
owned by the hook: isFormVisible, editingTreino, and handleEdit should no longer
be separate sources of truth since MeusTreinosClient now tracks editingTreinoId
locally. Update useWorkoutCRUD to keep only the CRUD state it still owns, and
adjust any returned values or handlers so edit behavior is driven from the
client component’s single edit-state flow.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/app/aluno/meus-treinos/meus-treinos-client.tsx">

<violation number="1" location="src/app/aluno/meus-treinos/meus-treinos-client.tsx:142">
P2: The async `onSave` callback unconditionally clears the global `editingTreinoId` after a successful save. Because other treino cards remain interactive during the save request, a user could switch to editing a different treino before the first save resolves. When the late success fires, it will close the wrong inline editor and potentially discard in-progress edits.

A safer pattern is to clear the editor only if the same treino is still being edited by using a functional state update.</violation>
</file>